Interfaces for digital media processing

ABSTRACT

APIs discussed herein promote efficient and timely interoperability between hardware and software components within the media processing pipelines of media content players. A PhysMemDataStructure API facilitates a hardware component&#39;s direct access to information within a memory used by a software component, to enable the hardware component to use direct memory access techniques to obtain the contents of the memory, instead of using processor cycles to execute copy commands. The PhysMemDataStructure API exposes one or more fields of data structures associated with units of media content stored in a memory used by a software component, and the exposed fields store information about the physical properties of the memory locations of the units of media content. SyncHelper APIs are used for obtaining information from, and passing information to, hardware components, which information is used to adjust the hardware components&#39; timing for preparing media samples of synchronously-presentable media content streams.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. Ser. No. 14/107,529, filedDec. 16, 2013, entitled, “INTERFACES FOR DIGITAL MEDIA PROCESSING”,which is a continuation of U.S. Ser. No. 11/824,720, filed Jun. 30,2007, entitled, “INTERFACES FOR DIGITAL MEDIA PROCESSING”, now U.S. Pat.No. 8,612,643, issued Dec. 17, 2013, which are incorporated herein byreference in their entirety.

BACKGROUND

Digital media presentations are composed of sequenced sets of mediacontent such as video, audio, images, text, and/or graphics. When mediacontent players render and/or present such sequenced sets of mediacontent to users, they are referred to as streams of media content. Somemedia content players are configured to concurrently render and presentmore than one independently-controlled stream of media content (forexample, a main movie along with features such as a director'scommentary, actor biographies, or advertising). Such media contentplayers may also be capable of rendering and presenting user-selectablevisible or audible objects (for example, various menus, games, specialeffects, or other options) concurrently with one or more streams ofmedia content.

Any type of device in the form of software, hardware, firmware, or anycombination thereof may be a media content player. Devices such asoptical media players (for example, DVD players), computers, and otherelectronic devices that provide access to large amounts of relativelyinexpensive, portable or otherwise accessible data storage areparticularly well positioned to meet consumer demand for digital mediapresentations having significant play durations.

It is common for various entities to supply different software andhardware components of media content players, and such components areexpected to successfully interoperate in environments having limitedprocessing and memory resources. It is therefore desirable to providetechniques for ensuring resource-efficient, relatively glitch-free playof digital media presentations, including the accurate synchronizationof concurrently presentable streams of media content, on all types ofmedia content players and architectures thereof.

SUMMARY

Digital media processing techniques and interfaces (such as applicationprogramming interfaces (“APIs”)) discussed herein promote efficient,consistent interoperability between hardware and software componentswithin a media processing pipeline associated with a media contentplayer.

Generally, a media processing pipeline is responsible for receiving setsof media content from media sources such as optical disks, hard drives,network locations, and other possible sources, and performing processingtasks to prepare the sets of media content for presentation to a user asone or more media content streams of a digital media presentation suchas a movie, television program, audio program, or other presentation.Sets of media content are referred to as “clips,” with one clipgenerally received from one media source. Discrete portions of clipsread from a particular media source are referred to herein as mediacontent units, which are generally demultiplexed, decompressed, decoded,and/or decrypted. After being demultiplexed, such media content unitsare referred to herein as media samples. It will be appreciated,however, that the naming convention(s) used herein is/are forillustrative purposes only, and that any desired naming conventions maybe used.

A media processing pipeline includes components such as media sourcereaders, demultiplexers, decoders, decrypters, and the like, which areimplemented in hardware or software or a combination thereof. Frameworkssuch as the Microsoft® DirectShow™ multimedia framework may be used toimplement a media processing pipeline. It will be appreciated, however,that any now known or later developed framework may be used to implementa media processing pipeline.

Information (such as information about the media content itself and/orpresentation of the media content to a user) is exchanged at boundariesbetween software components and hardware components in a mediaprocessing pipeline. In one information exchange scenario, informationwithin a memory (the term memory can encompass any type ofcomputer-readable storage medium) used by a software component is usableby a hardware component. In another information exchange scenario, ahardware component modifies its operation based on informationascertained by a software component, or vice-versa.

One exemplary technique and interface discussed herein—referred to fordiscussion purposes as the “PhysMemDataStructure” interface—isconfigured for operation at a boundary between a software component anda hardware component of a media processing pipeline to facilitate thehardware component's direct access of information from a memory used bythe software component, instead of using instructions/processor cyclesto copy the information. The PhysMemDataStructure interface exposes tothe hardware component one or more fields of data structures associatedwith units of media content (which are to be processed by the hardwarecomponent) stored in a memory used by the software component. The fieldsof the data structures store information about the physical propertiesof the memory where individual units of media content are located.Examples of such physical properties include but are not limited to typeof memory, memory block size, locations of read/write pointers to memorylocations, and offset locations of media content units with respect tosuch memory pointers. To further enhance the efficient use of memoryresources, the software component may store units of media content in aring buffer. To achieve still further memory and processingefficiencies, virtual memory may be used to duplicate the beginningportion of the ring buffer at the ending portion of the physical memoryring buffer.

Other exemplary techniques and interfaces discussed herein—referred tofor discussion purposes as the “SyncHelper” interfaces—are configured tofacilitate information exchange between hardware components and softwarecomponents, which may be used to adjust timing (to maintain perceivedsynchronization between two media content streams, for example) or otheroperational aspects of the hardware or software components. OneSyncHelper interface discussed herein—referred to as the“GetDecodeTimes” interface—provides information about a particular mediacontent unit or media sample being rendered by a hardware component(such as a demultiplexer, decoder, or renderer) at a particular point intime. The provided information includes the elapsed amount of the playduration of the digital media presentation at the particular point intime, as well as the elapsed amount of the play duration of the clipfrom which the media sample was derived. Another SynchHelperinterface—referred to as the “SyncToSTC” interface—facilitatessynchronization of various concurrently presentable media contentstreams. In an exemplary scenario, the SyncToSTC interface ascertains(that is, either requests/receives or calculates) a difference betweentwo values of the elapsed amount of the play duration of the digitalmedia presentation returned by the GetDecodeTimes interface, andinstructs one or more hardware components to adjust timing (for example,adjust the rate of a timing signal or adjust which media sample is beingdecoded or both) based on the ascertained difference.

This Summary is provided to introduce a selection of concepts in asimplified form. The concepts are further described in the DetailedDescription section. Elements or steps other than those described inthis Summary are possible, and no element or step is necessarilyrequired. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended foruse as an aid in determining the scope of the claimed subject matter.The claimed subject matter is not limited to implementations that solveany or all disadvantages noted in any part of this disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a simplified functional block diagram of an exemplary mediacontent player.

FIG. 2 is a schematic illustrating the exemplary media timeline(s) ofFIG. 1 in more detail.

FIG. 3 is a simplified functional block diagram illustrating aspects ofthe media content manager block of FIG. 1 in more detail.

FIG. 4 is a simplified functional block diagram illustrating anexemplary architecture for aspects of the media processing pipelineillustrated in FIG. 3.

FIG. 5 is a flowchart of a method for preparing media content forpresentation using aspects of the media content player shown in FIG. 1,a media processing pipeline shown in FIG. 3, and/or the architectureshown in FIG. 4.

FIG. 6 a flowchart of a method for preparing portions of two clips ofmedia content for synchronous presentation using aspects of the mediacontent player shown in FIG. 1, the media processing pipeline(s) shownin FIG. 3, and/or the architecture shown in FIG. 4.

FIG. 7 is a simplified block diagram of an exemplary configuration of anoperating environment in which all or part of the media content playershown in FIG. 1 or the methods shown in FIGS. 5 and 6 may be implementedor used.

FIG. 8 is a simplified block diagram of a client-server architecture inwhich aspects of the operating environment shown in FIG. 7 may beimplemented or used.

DETAILED DESCRIPTION

The predictable and relatively glitch-free play of a digital mediapresentation is often dependent on the efficient use of limitedcomputing resources of the media content player, especially memory andprocessor resources. Glitches and inefficiencies can arise in varioussituations, especially when information is transferred between hardwarecomponents and software components operating in a media processingpipeline. In one scenario, inefficiencies may arise when information istransferred between a memory used by a software component and a memoryused by a hardware component—it is desirable to minimize the processingand/or memory resources used in memory access transactions. In anotherscenario, glitches in the play of the media content stream(s) and/oruser-perceived loss of synchronization may occur when multiple mediacontent streams are prepared by separate hardware components forconcurrent presentation to a user and appropriate information is notavailable to the hardware components to ensure operationalsynchronization—it is desirable to provide information to the hardwarecomponents for use in adjusting the timing for performing certainprocessing tasks.

Various techniques and application programming interfaces (“APIs”) arediscussed herein that operate at a boundary between a software componentand a hardware component, to expose information usable by the hardwarecomponent to enhance the efficiency, accuracy and interoperability ofthe components operating in the media processing pipeline of a mediacontent player.

Turning now to the drawings, where like numerals designate likecomponents, FIG. 1 is a simplified functional block diagram of anexemplary media content player 100 (hereinafter referred to as“Presentation System” 100) that renders media content. Media content iscomposed of sequences (generally, time-ordered) of video, audio, images,text, and/or graphics. Presentation System may be any system thatrenders media content, including but not limited to an optical mediaplayer, a computing device or operating system thereof, an audio player,a set-top box, a telecommunication device, a personal digital assistant,an image or video capture device, and the like. For purposes ofdiscussion, it is assumed that Presentation System is an interactivemultimedia presentation system used to play media content such as moviesor other types of presentations in concurrently with user-selectablevisible or audible interactive objects (for example, menus, games,special effects, or other options).

As shown, Presentation System 100 includes a media content manager 102,an interactive content (“IC”) manager 104, a presentation manager 106, atiming signal management block 108, and a mixer/renderer 110. Ingeneral, design choices dictate how specific functions of PresentationSystem 100 are implemented. Such functions may be implemented usinghardware, software, or firmware, or combinations thereof.

In operation, Presentation System 100 handles interactive multimediapresentation content (“Presentation Content”) 120. Presentation Content120 includes a media content component (“media component”) 122 and aninteractive content component (“IC component”) 124. Media component 122and IC component 124 are generally, but need not be, handled separatelystreams, by media content manager 102 and IC manager 104, respectively.

Presentation System 100 facilitates presentation of Presentation Content120 to a user (not shown) as played presentation 127. Playedpresentation 127 represents the visible and/or audible informationassociated with Presentation Content 120 that is produced bymixer/renderer 110 and receivable by the user via devices such asdisplays or speakers (not shown). For discussion purposes, it is assumedthat Presentation Content 120 and played presentation 127 representaspects of high-definition DVD movie content, in any format. It will beappreciated, however, that Presentation Content 120 and PlayedPresentation 127 may be configured for presenting any type ofpresentation of media content now known or later developed.

Media component 122 represents one or more sequences (generally,time-ordered) of video, audio, images, text, and/or graphics presentableto users as media content streams (media content streams 308 and 328 areshown and discussed further below, in connection with FIG. 2) withinplayed presentation 127. More than one independently-controlled mediacontent stream may be concurrently presented (for example, a main moviealong with features such as a director's commentary, actor biographies,or advertising).

A movie generally has one or more versions (a version for matureaudiences, and a version for younger audiences, for example); one ormore titles 131 with one or more chapters (not shown) associated witheach title (titles are discussed further below, in connection withpresentation manager 106); one or more audio tracks (for example, themovie may be played in one or more languages, with or withoutsubtitles); and extra features such as director's commentary, additionalfootage, actor biographies, advertising, trailers, and the like. It willbe appreciated that distinctions between titles and chapters are purelylogical distinctions. For example, a single perceived media segmentcould be part of a single title/chapter, or could be made up of multipletitles/chapters. It is up to the content authoring source to determinethe applicable logical distinctions.

Sets of sequences of video, audio, images, text, and/or graphics thatform aspects of media component 122 are commonly referred to as clips123 (clips 123 are shown within media component 122 and playlist 128,and are also referred to in FIG. 2 and discussed further below). It willbe appreciated, however, that sets of data sequences that form mediacomponent 122 may be grouped and/or referred to in any desirable mannerand the actual data may be arranged into and represented by any desiredunits, for example, bits, frames, samples, data packets, groups ofpictures, enhanced video object units, etc. The digital contents of aparticular unit of data (and also the size of a unit of data) may bebased on several factors, such as the characteristics of the video,audio, or data content comprising the unit, or one or more parametersassociated with the media source from which the sample is derived (forexample, media source identity and/or location, encoder/decoderparameters or settings, or encryption parameters or settings). Mediasources are discussed further below, in connection with FIG. 2.

Media data 132 is data associated with media component 122 that has beenprepared for rendering by media content manager 102 and transmitted tomixer/renderer 110. Media data 132 generally includes, for each activeclip 123, a rendering of a portion of the clip.

Referring again to Presentation Content 120, IC component 124 includesinteractive objects 125, which are user-selectable visible or audibleobjects, optionally presentable concurrently with media component 122,along with any instructions (shown as applications 155) for presentingthe visible or audible objects. Examples of interactive objects include,among other things, video samples or clips, audio samples or clips,images, graphics, text, and combinations thereof.

Applications 155 provide the mechanism by which Presentation System 100presents interactive objects 125 to a user. Applications 155 representany signal processing method or stored instruction(s) thatelectronically control predetermined operations on data.

IC manager 104 includes one or more instruction handling engines 181,which receive, interpret, and arrange for execution of commandsassociated with applications 155. As execution of applications 155progresses and user input 150 is received, behavior within playedpresentation 127 may be triggered. Execution of certain instructions ofapplication 155, labeled as “input from ICM” 190, may facilitatecommunication or interoperability with other functionality or componentswithin Presentation System 100. As shown, input 190 is received by mediacontent manager 102 (discussed further below, in connection with FIG.2), but other components or functions within Presentation System 100 mayalso be responsive to input 190.

Interactive content data (“IC data”) 134 is data associated with ICcomponent 124 that has been prepared for rendering by IC manager 104 andtransmitted to mixer/renderer 110.

Timing signal management block 108 (discussed further below, inconnection with FIG. 3) produces various timing signals 158, which areused to control the timing for preparation and production of media data132 and IC data 134 by media content manager 102 and IC manager 104,respectively. For example, timing signal management block 108 isgenerally responsible for determining rates at which media data 132(“media data presentation rate 207,” shown and discussed in connectionwith FIG. 3) and IC data 134 are presented to a user. In anotherexample, timing signals 158 are used to achieve approximatesynchronization of media data 132 and/or IC data 134 (for example,timing/synchronization on a per-frame basis or on another time basis).

Mixer/renderer renders media data 132 in a video plane (not shown), andrenders IC data 134 in a graphics plane (not shown). The graphics planeis generally, but not necessarily, overlayed onto the video plane toproduce played presentation 127 for the user.

Presentation manager 106, which is configured for communication withmedia content manager 102, IC manager 104, mixer/renderer 110, andtiming signal management block 108, facilitates handling of PresentationContent 120 and presentation of played presentation 127 to the user.Presentation manager 106 has access to a playlist 128. Playlist 128includes, among other things, a time-ordered sequence of clips 123 andapplications 155 (including interactive objects 125) that arepresentable to a user. The clips 123 and applications 155/interactiveobjects 125 may be arranged to form one or more titles 131. As discussedabove, it is possible for more than one independently-controlledtitle/media content stream to be concurrently played to a user. Suchconcurrently played streams may be indicated on playlist 128, orserendipitous user input may cause concurrent play of media contentstreams.

Presentation manager 106 uses playlist 128 to ascertain a presentationtimeline 130 for a particular media presentation (a title 131 in thecase of a movie), which generally has a predetermined play durationrepresenting the particular amount of time in which the title ispresentable to a user. Representations of amounts of specific elapsedtimes within the play duration are often referred to as “title times”.Because a title may be played once or more than once (in a loopingfashion, for example), the play duration is determined based on oneiteration of the title. Conceptually, presentation timeline 130indicates the title times when specific clips 123 and applications 155are presentable to a user (although as indicated, it is not generallyknown when user inputs starting and stopping the play of some specificclips may occur). Specific clips 123 also generally have predeterminedplay durations representing the particular amounts of time forpresenting the clip. Representations of amounts of specific elapsedtimes within the clip play durations are often referred to as“presentation times”. Each individually-presentable portion of a clip(which may for discussion purposes be referred to as a “media sample,”although any desired naming convention may be used) has an associated,pre-determined presentation time within the play duration of the clip.To avoid user-perceptible glitches in the presentation of media content,one or more upcoming media samples are prepared for presentation inadvance of the scheduled/pre-determined presentation time.

To better illustrate the play of a particular clip and timing/timesassociated therewith, it is useful to use playlist 128 and/orpresentation timeline 130 to ascertain one or more media contenttimelines (“media timeline(s)”) 142. With continuing reference to FIGS.1 and 2, FIG. 3 is an exemplary media timeline 142 for a particular clip123. Various media sample presentation times 202 are indicated on mediatimeline 142. Media sample presentation times 202 represent times withinthe play duration of a particular clip at which one or more mediasamples are presentable as media data 132. As shown, media samplepresentation times 202 occur at a rate based on a predetermined mediadata presentation rate 207, which may vary from clip-to-clip. Note thatit is not necessary for media data presentation rate 207 to be the sameas the rate at which a particular clip 123 was encoded, although themedia data presentation rate may change based on the encoding rate for aparticular clip. Certain user input 150 can also affect the speed ofmedia sample retrieval from media sources and thus affect the rate atwhich media sample presentation times 202 occur. For example, playedpresentation 127 may proceed in a forward direction at a normal speed,and may also proceed in both forward and reverse directions at speedsfaster or slower than the normal speed. It will appreciated that normalspeed is a relative term, and that normal speed may vary frompresentation to presentation, and from clip-to-clip. During fast-reverseand fast-forward operations, the playing of certain media content (asshown, media samples 230) is often skipped. Other user input may causethe playing of certain content to be skipped, such as when the userjumps from one part of the movie to another.

A current elapsed play time 209 (that is, the title time of the digitalmedia presentation with which the clip is associated) is shown on mediatimeline 142. Media sample 250 is being presented to a user at currentelapsed play time 209. As shown, current elapsed play time 209 coincideswith a particular media sample presentation time 202, although suchcoinciding is not necessary. A next presentable media samplepresentation time 214 is also shown. Next presentable media samplepresentation time 214 is used to determine the next media sample, and/orthe next media sample presentation time, that should be next preparedfor presentation to a user (as shown, next processable media sample 270is to be prepared for presentation). It will be appreciated that thenext presentable media sample/presentation time may be the nextconsecutive media sample/presentation time based on playlist 128, or maybe a media sample/presentation time one or more mediasamples/presentation times 202 away from the media sample/presentationtime associated with current elapsed play time 209. There are variousways to ascertain the next presentable media sample/media samplepresentation time, which are not discussed in detail herein. Generally,however, a predicted elapsed play time 220 (that is, predicted titletime of the play duration of the digital media presentation) and thecorresponding next presentable media sample/presentation time areascertained. Information such as the play speed, media frame rate 207,and other information may be used to determine the predicted elapsedplay time and/or locate the particular media sample presentationtime/media sample.

Referring again to FIG. 1, in operation, presentation manager 106provides information, including but not limited to information aboutpresentation timeline 130 and/or media timeline 142 to media contentmanager 102 and IC manager 104. Based on input from presentation manager106, IC manager 104 prepares IC data 134 for rendering, and mediacontent manager 102 prepares media data 132 for rendering.

With continuing reference to FIGS. 1 and 2, FIG. 3 is a simplifiedfunctional block diagram illustrating aspects of media content manager102 in more detail. Media content manager 102 includes one or more mediaprocessing pipelines. Two media processing pipelines are shown, mediaprocessing pipeline1 302 and media processing pipeline2 320, althoughany number of media processing pipelines is possible. Generally, mediaprocessing pipeline1 302 and media processing pipeline2 320 are used toprepare independently-controlled media content streams 308 and 328,respectively, for presentation to a user. One media processing pipelineis usually responsible for preparing a primary media content stream,such as a movie, with reference to a first timing signal 1 350, andother media processing pipelines are responsible for preparing one ormore secondary media content streams, such as director's commentary,actor biographies, advertising, etc., with reference to a second timingsignal 2 370. Timing signals represent the rate(s) at which samples ofmedia content are retrieved from media sources and/or prepared forpresentation to a user (such rate(s) may change dynamically, however,based on user input, encoding/encryption/compression formats, and otherfactors), and are generally derived from clocks sources (not shown),such as clock sources associated with Presentation System 100 and/orspecial-purpose devices such as hardware components within mediaprocessing pipelines.

Media content manager 102 is responsible for preparing upcomingindividually-presentable portions of clips, such as next processablemedia sample(s) 270 shown in FIG. 2, for presentation. Such preparationoften involves multiple steps, including but not limited to reading theupcoming portion of the clip from a particular media source (mediasources 304 and 324 shown, which are any devices, locations, or datafrom which media content is derived or obtained), and using hardware-and software-based media processing components (media processingcomponents 306 and 326 are shown and discussed further below inconnection with FIG. 4) such as readers, demultiplers, decoders,renderers, and/or decrypters to obtain playable media content streams308, 328 from the information read from the media source(s).

It will be appreciated that media content manager 102 may have a dynamicprocessing load based on the identity and scheduling (pre-determined orbased on serendipitous user input 150) of the various clips 123comprising media component 122 and/or IC component 124. Generally, it isdesirable for media processing pipelines to consume no more than 10-15%of the processing resources (for example, CPU cycles) of PresentationSystem 100.

Large amounts of processing resources can be consumed when informationis transferred between memory locations using traditional copytransactions such as memory-to-memory copies, and the over-use ofprocessing resources for copy transactions has the potential to causeglitches in the play of a digital media presentation. Yet, it is oftendesirable to transfer information between memories used by differentcomponents of media processing pipelines, especially between memoriesused by software components and memories used by hardware components.Hardware components are used, among other reasons, to accelerate mediacontent processing.

Contemporaneously preparing for presentation upcoming portions of two ormore clips can also consume large amounts of computing resources such asmemory and processor cycles in a manner that is not easily predictable,and can further exacerbate the potential for glitches in the play ofdigital media content. Moreover, memory and/or processing resourcesrequired to prepare a particular portion of a clip for presentation (andthus times for such preparation) are not always constant fromsample-to-sample or clip-to-clip. Some factors that affect requiredresources and preparation times are associated with the media contentitself (including but not limited to factors such as media unit/samplesize, media source/location, encoding or decoding parameters, andencryption parameters). Other factors that affect required resources areassociated with the media content player (for example, media processingpipeline architecture, dynamic processing loads, and other features ofmedia content player architecture), while still other factors thataffect required resources are associated with user input (user-selectedmedia content, content formats, or play speeds, for example).

With continuing reference to FIGS. 1-3, FIG. 4 is a simplifiedfunctional block diagram illustrating architectural and operationalaspects of media processing component blocks 306 and 326 in more detail.In one possible implementation, the Microsoft® DirectShow™ multimediaframework is used to divide media processing tasks into groups of stepsknown as filters, with each filter having a number of input pins and anumber of output pins that connect filters together. It will beappreciated, however, that any now known or later developed frameworkmay be used to implement a media processing pipeline.

As shown, a software-hardware boundary 403 is indicated by a dashedline—components on the left side of boundary 403 are primarilysoftware-based components (or portions of components implemented usingsoftware), and components on the right side of boundary 403 areprimarily hardware-based components (or portions of componentsimplemented using hardware or firmware or a combination thereof). Anexemplary architecture includes a software-based media source reader 402having access to a first memory 430 from which a hardware-basedcomponent can directly read from; a hardware-based demultiplexer(“demux”) 404 generally having access to one or more blocks of memory(shown and referred to as a second memory 433 for discussion purposes);one or more hardware-based decoders/renderers 490 also generally havingaccess to one or more blocks of memory (shown and referred to as secondmemory 433 for discussion purposes); one or more hardware-baseddecoders/renderers 490 also generally having access to one or moreblocks of memory (shown and referred to as second memory 433 fordiscussion purposes); and application programming interfaces 408, whichinclude a PhysMemDataStructure API 410, Sniffer/Callback APIs 422, andSyncHelper APIs 416 including GetDecodeTimes API 418 and SyncToSTC API440.

Media source reader 402 is responsible for receiving (via data push orpull techniques) individually-presentable portions of clips (referred tofor discussion purposes as media units 407) from a particular mediasource, storing the received media units 407 in memory 430, and forpassing data regarding the stored media units 407 downstream (to demux404 or decoders/renderers 490, for example). In one possibleimplementation, data is passed downstream to demux 404 using datastructures. In the context of a Microsoft® DirectShow™ framework, forexample, media units 407 are wrapped in data structures referred to asIMediaSample objects (IMediaSample references an interface the objectsimplement, the objects may be referred to as Media Samples). OftenIMediaSample objects are constrained to a fixed size allocation atinitialization time, and depending on sizes of media content units, maynot be used to their full extent. Using a ring buffer 420 as discussedbelow enables more efficient use of memory.

Memory 430 represents any computer-readable medium (computer-readablemedia are discussed further below, in connection with FIG. 7) accessiblevia the operating system of Presentation System 100, including but notlimited to physically contiguous and scatter-gathered memory, virtuallycached and uncached memory, physically locked and unlocked (forscatter-gather type) memory, and virtual memory mapping optimized forusage by a ring buffer 420 (discussed further below). Hardware-allocatedmemory block 432 is an abstract representation of an amount or area (ofany size or configuration) of memory 430 that can be viewed as havingblocks that may be separately allocated, via media source reader 402,for access by demux 404 (or other components of media processingpipelines 302 or 320) in accordance with certain algorithms (anexemplary algorithm is shown and discussed below, in connection withFIG. 5) and via use of certain APIs 408, such as PhysMemDataStructureAPI 410. In one exemplary implementation, hardware-allocated memoryblock 432 is ring buffer 420 having blocks in which individual mediacontent units 407 obtained from media source reader 402 are stored. Anadvantage of using ring buffer 420 is that some computer-readable mediacan be read more efficiently when data is read via tracks, especiallywhen ring buffer 420 does not put any packet constraints on the readoperation (for example, from an optical device). Another advantage ofusing ring buffer 420 is for trick modes, when data is read faster thanusual (from an optical drive, for example). Skipping parts of mediacontent units that are not required to perform a full decode is moreeasily achieved with the chunking mechanism built into the ring bufferreader. Other details of ring buffer 420 and the benefits and operationthereof are discussed further below, in connection with FIG. 5.

Demux 404 is responsive to receive media units 407 (such as nextprocessable media sample(s) 270, shown in FIG. 2) and/or data structuresassociated with media units 407 at input pin 411 from output pin 401 ofmedia source reader 402, and to separate two or more signals (such asdecoded streams of media content) that were previously combined by acompatible multiplexer. Memory(ies) 433 represent(s) one or morecomputer-readable media (computer-readable media are discussed furtherbelow, in connection with FIG. 7), such as buffers or registers, usableby demux 404 or other hardware components. Demux 404 providesdemultiplexed media samples 409 associated with individual media contentstreams (such as media content streams 308 or 328) on output pin 421 toan input pin 491 of decoders/renderers 490.

Decoders/renderers 490 are responsible for receiving demultiplexed mediaunits, referred to for discussion purposes as media samples 409 (MPEG-2samples, for example), and for using generally well-known techniques forunscrambling/unencrypting the demultiplexed media samples to producemedia data 132 associated with a particular media content stream 308,328. Although a one-to-one relationship between media sources,demultiplexers, and decoders/renderers is shown, it will be appreciatedthat any arrangement of any number of such components (along withadditional components) is possible, and that such components may beshared between media processing pipeline1 302 and media processingpipeline2 320.

APIs 408 are provided to enhance the interoperability of softwarecomponents and hardware components within a media processing pipeline,and to promote the efficient use of memory and processing resources ofPresentation System 100. In one possible implementation, APIs 408 aresets of computer-executable instructions encoded on computer-readablestorage media that may be either executed during operation ofPresentation System 100 and/or accessed by authors of instructions formedia processing components 306 and 326. Generally, APIs 408 areconfigured to perform aspects of the method(s) shown and discussedfurther below in connection with FIGS. 5 and 6.

PhysMemDataStructure API 410 is configured to generalize the support ofmemory 430 that can be directly consumed by hardware components such asdemux 404 and decoders/renderers 490. In one possible implementation (inthe context of a media processing pipeline having a DirectShow™framework, for example) media units 407 wrapped in IMediaSample objectsare allocated (by means of an implementation of an IMemAllocator object(using input pin 411 of demux 404, for example—output pin 401 wouldquery input pin 411, so demux 404 can provide memory with propertiesusable/needed by the hardware) to storage locations withinhardware-allocated memory block 432, and information about such storagelocations (such as the type memory; a size of a memory block; a locationof a pointer to the memory; and an offset location of a storage locationof a particular media unit with respect to a pointer to the memory) isexposed to hardware components such as demux 404 and decoders/renderers490 by PhysMemDataStructureAPI 410. Hardware components are thereby ableto directly access/retrieve information within hardware-allocated memoryblock 432 (via direct memory access techniques, for example), instead ofusing instructions and processor cycles to copy the information.

Exemplary pseudo-code usable for implementing PhysMemDataStructureAPI410 in the context of media processing pipelines 302, 320 and/or mediaprocessing components 306, 326 is shown below.

   interface IPhysMemMediaSample : IUnknown {  // S_OK == contigousphysical memory, S_FALSE scatter/gather method required  HRESULTIsContigous( );  // S_OK == cached memory, S_FALSE uncached  HRESULTIsCached( );  // S_OK == memory is ready for dma operation  // S_FALSE== memory needs PageLock/Unlock for DMA  HRESULT IsPageLocked( );  //S_OK == yirtual memory pointer wraps around to start of  // physicalbuffer when exceeding ring buffer size,  // S_FALSE no wrap  HRESULTIsAutoWrap( );  // page size for scatter / gather table  HRESULTPageSize(   [out] DWORD *pPageLength   );  // allow to buildscatter/gather table after memory is locked  HRESULT GetPhysicalPointer(  [in] DWORD offset,   [out] DWORD *pPhysAddress,   [out] DWORD *pLength  );  // allow to build scatter/gather table after memory is locked  // HRESULT GetScatterGatherTable(   [in] DWORD size,   [out,size_is(size)] DWORD *pTable,   [out] DWORD *pEntries   );  // size inbytes for DWORD array required to build  // scatter gather table HRESULT GetScatterGatherTableSize(   [out] DWORD *pSize   );  // lock /unlock physical pages in buffer  HRESULT PageLock( );  HRESULTPageUnlock( );  // cache writeback & discard  // use before dma frommedia sample buffer to hardware  HRESULT CacheSyncWriteback(   [in]DWORD offset,   [in] DWORD length   );  // cache discard / invalidate // use before dma from hardware to media sample buffer  HRESULTCacheSyncDiscard(   [in] DWORD offset,   [in] DWORD length   ); };

Sniffer/Callback APIs 422 are used to provide access by software-basedelements of Presentation System 100 to certain media samples 409 (forexample, “HLI,” “ADV,” and “NAV” packets multiplexed in ahigh-definition DVD program stream) that have been parsed by demux 404and/or media data 132 that has been decoded/rendered bydecoders/renderers 490. In one possible implementation, a DirectShow™framework filter is connected to output pin 421 of demux 404 or anoutput pin (not shown) of decoders/renderers 490, and this filter isused to support the Sniffer/Callback APIs 422.

Exemplary pseudo-code usable for implementing a Sniffer/Callback APIthat will detect certain types of media samples 409 or media data 132 inthe context of media processing pipelines 302, 320 and/or mediaprocessing components 306, 326 is shown below.

 HRESULT RegisterCallback( [in] IRendererDataCallB ack* pCallBack );In return, the callback renderer calls

HRESULT Callback(  [in] IMediaSample* pMediaSample   );

SyncHelper APIs 416 are configured to facilitate information exchangeusable to maintain perceived synchronization between media contentstreams 308 and 328. GetDecodeTimes API 418 is configured to providestatus notifications about certain times (such as title times 209 andmedia sample presentation times 202) associated with times at whichcertain media samples (for example, media units 407 or media samples 409deemed to be next processable media samples 270) are being prepared forpresentation by a hardware component (such as demux 404 or one or moredecoders/renderers 490). Information provided via the SyncToSTC API 440may be used, among other things, to adjust timing signals 350 and/or 370based on differences in title times 209 returned by GetDecodeTimes API418 from different decoders/renderers (or other hardware components)processing synchronously presentable media samples.

Exemplary pseudo-code usable for implementing SyncHelper APIs 416 isshown below.

/*++  Implemented on the renderes  Helper functions to synchronizestreams and provide information about PTS and STC times interfaceISyncHelper : IUnknown {  // Returns the current STC time and the PTS ofthe sample currently being decoded in  // PTS TIME BASE ticks  // HRESULT  GetDecodeTimes (   [out] PTS_TIME* ptSTC, // current STC time(global)   [out] PTS_TIME* ptPTS // current PTS time   ) ;  //  //Synchonize two sessions. Provides delta off the STC time to rendersamples,  //  HRESULT  SyncToSTC (   [in] STC_IDENTIFIER  stcToSyncTo,// the clock to sync to   [in] PTS_TIME tDelta // delta off the STC torender samples at, can be -ve   ); };

With continuing reference to FIGS. 1-4, FIGS. 5 and 6 are flowcharts ofmethods for preparing media content (such as portions of one or moreclips 123) for presentation by one or more media processing pipelines(such as media processing pipeline1 302 or media processing pipeline2320) using the functionality provided by one or more APIs 408. Themethod shown in FIG. 5 is useful to minimize the processing and/ormemory resources used when information is transferred between a memory(such as memory 430) used by a software component (such as media sourcereader 402 or another software component) and a memory (such as memory433) used by a hardware component (such as demux 404 ordecoders/renderers 490 or other hardware components). The method shownin FIG. 6 is useful to maintain perceived synchronization when portionsof multiple concurrently playable media content streams are prepared forpresentation by separate hardware components.

The processes illustrated in FIGS. 5 and 6 may be implemented in one ormore general, multi-purpose, or single-purpose processors, such asprocessor 702 discussed below in connection with FIG. 7. Unlessspecifically stated, the methods described herein are not constrained toa particular order or sequence. In addition, some of the describedmethods or elements thereof can occur or be performed concurrently.

Referring to the method shown in the flowchart of FIG. 5, the methodbegins at block 500 and continues at block 502, where a portion of afirst memory, such as hardware-allocated memory block 432, is identifiedfor storing media content units such as individually-playable portionsof a clip 123 (such as media units 407 received from a particular mediasource 304). A particular media content unit and a storage location forthe media content unit in the first memory are identified at blocks 504and 506, respectively.

In the context of media processing components 306, 326 of mediaprocessing pipelines 302, 320, respectively, hardware-allocated memoryblock 432 may be implemented as ring buffer 420 to enhance the efficientuse of memory and processing resources. Ring buffer 420 can be viewed ashaving blocks that may be separately allocated, via media source reader402 (or other components of media processing pipelines 302 or 320), forstoring media units 407. The offset of each media unit 407 stored inring buffer 420 is known, and can be expressed relative to the values ofone or more pointers to locations within ring buffer 420, such as abeginning of memory (“BOM”) pointer 435, an end of memory (“EOM”)pointer 437, a beginning of used memory pointer (“BUMP”) 453, and/or anend of used memory pointer (“EUMP”) 455. As demux 404 or anotherhardware component obtains representations of media units 407 from ringbuffer 420, BUMP 453 and/or EUMP 455 may be moved accordingly. Becausemedia units 407 may be obtained and released out of order, a list ofoffsets of media units 407 within ring buffer 420 may be maintained toensure that BUMP 453 and EUMP 455 are not permitted to bypass eachother.

To further enhance memory use and processing efficiencies, virtualmemory may be used to duplicate one or more memory blocks from thebeginning of ring buffer 420 to the end of ring buffer 420. As shown,duplicate BOM block 450 (which is a duplicate of beginning-of-memory“BOM” block 450) is implemented using virtual memory, and is logicallylocated after end-of-memory “EOM” block 441. This use of virtual memoryis referred to as the “auto-wrap” function, because it is especiallyuseful when breaking up a larger block of memory to be used in a ringbuffer fashion with read and write pointers. Use of the auto-wrapfunction is optional—generally the provider of demux 404 can choose toprovide memory that does not map twice and the media processing pipelinewill still work, but may make less efficient use of memory. In such aring buffer implementation there is the special case that the piece ofmemory that “wraps around” to the beginning of the buffer may requirespecial treatment. For example, copying or otherwise obtaining theinformation in the portion of memory that wraps around may require twotransactions—one transaction to retrieve the information in the end ofthe buffer, and another transaction to retrieve the information in thebeginning of the buffer. Thus, it is usually difficult to take fulladvantage of the ring buffer size. Use of virtual memory as describedabove avoids the need to either allocate extra memory or skip to the endof the ring buffer (both result in inefficient use of memory) when theinformation size is too large to fit at the end of the ring buffer.

Exemplary code usable (for Microsoft® Windows CE 6.0 operating systemsoftware, although any operating system using virtual memory may beused) for implementing an “auto-wrap” feature that maps a physical pieceof memory twice to a double-sized virtual memory region is shown below.

// map physical memory twice to double sized virtual memory region CallerProc = GetCallerProcess( );  VirtualAddress =VirtualAllocEx(CallerProc, 0, Size*2, MEM_RESERVE, PAGE_NOACCESS); VirtualCopyEx(CallerProc , VirtualAddress,   GetCurrentProcess( ),(PVOID)( PhysicalAddress>> 8), Size,   PAGE_PHYSICAL | PAGE_READWRITE |(Cached ? 0 : PAGE_NOCACHE)) )  VirtualCopyEx(CallerProc , (PBYTE)VirtualAddress+Size,   GetCurrentProcess( ), (PVOID)( PhysicalAddress>>8), Size,   PAGE_PHYSICAL | PAGE_READWRITE | (Cached ? 0 :PAGE_NOCACHE))

Referring again to the flowchart of FIG. 5, block 508 illustrates thestep of forming a data structure associated with the particular mediacontent unit, the data structure having a field for storing informationabout the storage location of the media content unit in the firstmemory. Next, at block 510, the data structure is exposed to a hardwarecomponent (such as demux 404 or decoders/renderers 490) that has asecond memory. At block 512, it can be seen that the hardware componentcan use the information in the data structure about the storage locationof the media content unit to directly transfer the media content unitfrom the first memory to the second memory, without a central processingunit.

In the context of media processing components 306, 326 implemented usingDirectShow™ frameworks, media source reader 402 uses data structuressuch as IMediaSampleObjects to provide all or some of the followinginformation to downstream hardware components: pointers to memory 430and/or hardware-allocated memory block 432; size of memory 430 and/orhardware-allocated memory block 432; start and stop times of media units407; flag(s); and any other desired information. Advantageously,information regarding properties of memory blocks of ring buffer 420allocated by media source reader 402 for access by demux 404 (and otherhardware components) are exposed via PhysMemDataStructure API 410, whichmay also be provided by a data structure (or fields thereof) such as theIMediaSampleObject. Physical memory information derived by demux 404 andother hardware components from the PhysMemDataStructure API 410 are usedto directly access storage location of individual media content units407 within ring buffer 420, largely obviating the need forprocessor-intensive copy transactions such as “memcopy” transactions.Information regarding properties of hardware-allocated memory block 432that is exposed via the PhysMemDataStructure API 410 include but is notlimited to: the type of memory 432; a size of a memory block of thememory; a location of one or more pointers 437, 435, 453, or 455 to thememory; and an offset location of a particular media unit 407 withrespect to one or more pointers to the memory.

Referring to the method shown in the flowchart of FIG. 6, the methodbegins at block 600 and continues at blocks 602 and 604, where,respectively, a play duration of a multimedia presentation isidentified, and two clips (each having their own play durations)playable as separate media content streams, such as media content stream308 and media content stream 328, are identified. Next, twosynchronously presentable media samples, one from the first clip and onefrom the second clip, are identified, at blocks 606 and 608,respectively.

Generally, software-based components of Presentation System (such asaspects of presentation manager 106) are aware of currently playableclips 123. In the context of media processing components 306, 326 ofmedia processing pipelines 302, 320, respectively, it is possible to useSniffer/Callback APIs 422 to identify specific media units 407 and/ormedia samples 409 being processed by demux 404 and/or decoders/renderers490.

As indicated at block 610, certain information is ascertained at a firsttime—the first time associated with when the media sample from the firstclip is undergoing preparation for presentation by a first hardwarecomponent, such as demux 404 or decoder/renderer 490 within mediaprocessing pipeline1 302. The following information is ascertained atblock 610: an elapsed amount of the play duration of the digital mediapresentation, and an elapsed amount of the play duration of the firstclip.

As indicated at block 612, certain information is ascertained at asecond time—the second time associated with when the media sample fromthe second clip is undergoing preparation for presentation by a secondhardware component, such as demux 404 or decoder/renderer 490 withinmedia processing pipeline2 322. The following information is ascertainedat block 612: an elapsed amount of the play duration of the digitalmedia presentation, and an elapsed amount of the play duration of thesecond clip.

As discussed above in connection with the media exemplary media timelineshown in FIG. 2, the elapsed amount of the play duration is oftenreferred to as the title time (or the global system time), and anelapsed amount of the play duration of a particular clip generallycorresponds to a particular pre-determined media sample presentationtime 202 associated with a particular media sample. The GetDecodeTimesAPI 418 is configured to examine media samples and/or media timelines142 of both the first and second clips, and to return the informationindicated at blocks 610 and 612.

At block 614, the difference between the elapsed amount of the playduration of the digital media presentation calculated at block 610 andthe elapsed amount of the play duration of the digital mediapresentation calculated at block 612 is ascertained, and, as indicatedat block 616, is usable to adjust timing of the hardware components forpreparing and/or presenting media samples.

In the context of media processing components 306, 326 of mediaprocessing pipelines 302, 320, respectively, the SyncToSTC API 440 isconfigured to use information obtained via the GetDecodeTimesAPI 418 tosynchronize various media content streams from different hardwarecomponents, by applying deltas (based on the difference between theelapsed amount of the play duration ascertained at block 614) toprocessing times and/or timing signals, such as timing signals 350 and370. It will be appreciated that the SyncToSTC API 440 can also be usedto synchronize media content streams with other playback constraints(for example, as defined by a playlist).

With continued reference to FIGS. 1-6, FIG. 7 is a block diagram of anexemplary configuration of an operating environment 700 in which all orpart of Presentation System 100 may be implemented or used. Operatingenvironment 700 is generally indicative of a wide variety ofgeneral-purpose or special-purpose computing environments. Operatingenvironment 700 is only one example of a suitable operating environmentand is not intended to suggest any limitation as to the scope of use orfunctionality of the system(s) and methods described herein. Forexample, operating environment 700 may be a type of computer, such as apersonal computer, a workstation, a server, a portable device, a laptop,a tablet, or any other type of electronic device, such as an opticalmedia player or another type of media player, now known or laterdeveloped, or any aspect thereof. Operating environment 700 may also bea distributed computing network or a Web service, for example. Aspecific example of operating environment 700 is an environment, such asa DVD player or an operating system associated therewith, whichfacilitates playing high-definition DVD movies.

As shown, operating environment 700 includes or accesses components of acomputing unit, including one or more processors 702, computer-readablemedia 704, and computer programs 706. Processor(s) 702 is/are responsiveto computer-readable media 704 and to computer programs 706.Processor(s) 702 may be physical or virtual processors, and may executeinstructions at the assembly, compiled, or machine-level to perform aparticular process. Such instructions may be created using source codeor any other known computer program design tool.

Computer-readable media 704 represent any number and combination oflocal or remote devices, in any form, now known or later developed,capable of recording, storing, or transmitting computer-readable data,such as the instructions executable by processor 702. In particular,computer-readable media 704 may be, or may include, a semiconductormemory (such as a read only memory (“ROM”), any type of programmable ROM(“PROM”), a random access memory (“RAM”), or a flash memory, forexample); a magnetic storage device (such as a floppy disk drive, a harddisk drive, a magnetic drum, a magnetic tape, or a magneto-opticaldisk); an optical storage device (such as any type of compact disk ordigital versatile disk); a bubble memory; a cache memory; a core memory;a holographic memory; a memory stick; a paper tape; a punch card; or anycombination thereof. Computer-readable media 704 may also includetransmission media and data associated therewith. Examples oftransmission media/data include, but are not limited to, data embodiedin any form of wire line or wireless transmission, such as packetized ornon-packetized data carried by a modulated carrier signal. The abovenotwithstanding, computer-readable media 704 does not include any formof propagated data signal.

Computer programs 706 represent any signal processing methods or storedinstructions that electronically control predetermined operations ondata. In general, computer programs 706 are computer-executableinstructions implemented as software components according to well-knownpractices for component-based software development, and encoded incomputer-readable media (such as computer-readable media 704). Computerprograms may be combined or distributed in various ways.

Storage 714 includes additional or different computer-readable mediaassociated specifically with operating environment 700, such as anoptical disc or other portable (optical discs are handled by optionaloptical disc drive 716). One or more internal buses 720, which arewell-known and widely available elements, may be used to carry data,addresses, control signals and other information within, to, or fromoperating environment 700 or elements thereof.

Input interface(s) 708 provide input to computing environment 700. Inputmay be collected using any type of now known or later-developedinterface, such as a user interface. User interfaces may be touch-inputdevices such as remote controls, displays, mice, pens, styluses,trackballs, keyboards, microphones, scanning devices, and all types ofdevices that are used input data.

Output interface(s) 710 provide output from operating environment 700.Examples of output interface(s) 710 include displays, printers,speakers, drives (such as optical disc drive 716 and other disc drivesor storage media), and the like.

External communication interface(s) 712 are available to enhance theability of operating environment 700 to receive information from, or totransmit information to, another entity via a communication medium suchas a channel signal, a data signal, or a computer-readable medium.External communication interface(s) 712 may be, or may include, elementssuch as cable modems, data terminal equipment, media players, datastorage devices, personal digital assistants, or any other device orcomponent/combination thereof, along with associated network supportdevices and/or software or interfaces.

FIG. 8 is a simplified functional diagram of a client-serverarchitecture 800 in connection with which the Presentation System 100 oroperating environment 700 may be used. One or more aspects ofPresentation System 100 and/or operating environment 700 may berepresented on a client-side 802 of architecture 800 or on a server-side804 of architecture 800. As shown, communication framework 803 (whichmay be any public or private network of any type, for example, wired orwireless) facilitates communication between client-side 802 andserver-side 804.

On client-side 802, one or more clients 806, which may be implemented inhardware, software, firmware, or any combination thereof, are responsiveto client data stores 808. Client data stores 808 may becomputer-readable media 704, employed to store information local toclients 806. On server-side 804, one or more servers 810 are responsiveto server data stores 812. Like client data stores 808, server datastores 812 may include one or more computer-readable media 704, employedto store information local to servers 810.

Various aspects of a presentation system that is used to presentinteractive content to a user synchronously with media content have beendescribed. It will be understood, however, that all of the describedcomponents of the presentation system need not be used, nor must thecomponents, when used, be present concurrently. Functions/componentsdescribed in the context of Presentation System 100 as being computerprograms are not limited to implementation by any specific embodimentsof computer programs. Rather, functions are processes that convey ortransform data, and may generally be implemented by, or executed in,hardware, software, firmware, or any combination thereof.

Although the subject matter herein has been described in languagespecific to structural features and/or methodological acts, it is alsoto be understood that the subject matter defined in the claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims.

It will further be understood that when one element is indicated asbeing responsive to another element, the elements may be directly orindirectly coupled. Connections depicted herein may be logical orphysical in practice to achieve a coupling or communicative interfacebetween elements. Connections may be implemented, among other ways, asinter-process communications among software processes, or inter-machinecommunications among networked computers.

The word “exemplary” is used herein to mean serving as an example,instance, or illustration. Any implementation or aspect thereofdescribed herein as “exemplary” is not necessarily to be constructed aspreferred or advantageous over other implementations or aspects thereof.

As it is understood that embodiments other than the specific embodimentsdescribed above may be devised without departing from the spirit andscope of the appended claims, it is intended that the scope of thesubject matter herein will be governed by the following claims.

What is claimed is:
 1. A method for preparing media content as a mediapresentation by a software-based media player including adecoder/renderer, the media content receivable from a media source as aplurality of media content units, the method comprising: identifying aportion of a memory having blocks that are configured to be separatelyallocated, the portion allocated for storing media content unitscomprising individually-presentable portions of clips received from themedia source, the individually-presentable portions of clips beingmultiplexed into a single program stream comprising the mediapresentation received at a hardware component, the hardware componentproviding scheduling information, responsively to a timing signal, tothe decoder/renderer to enable time-based synchronization of theindividually-presentable portions of clips, identifying a plurality ofmedia content units received from the media source; identifying storagelocations and offsets within the memory in which each of the pluralityof media content units has been stored in the allocated portion of thememory; forming data structures associated with each of the plurality ofmedia content units, the data structures each having a field for storinginformation about the storage location of a particular media contentunit; arranging for exposure of the data structures to the hardwarecomponent, the information about the storage locations of the particularmedia content units obtained from the data structures usable by thehardware component to directly access the particular media content unitsfrom the memory without using a central processing unit; and after aparticular media content unit has been accessed, releasing theparticular media content unit from the storage location.
 2. The methodaccording to claim 1, wherein the portion of the memory allocated forstoring media content units received from the media source is selectedfrom the group consisting of: a contiguous physical memory, a lockedscatter-gathered physical memory, an unlocked scatter-gathered physicalmemory, a cached virtual memory, and an uncached virtual memory, andwherein the information about the storage locations exposed by the datastructure is selected from the group consisting of: a type of thememory; a size of a memory block of the memory; a location of a pointerto the memory; and an offset location of the storage location withrespect to a pointer to the memory.
 3. The method-readable mediumaccording to claim 1, wherein the method is performed within a mediaprocessing pipeline comprising a filter graph having a plurality offilters, each filter having one or more input pins and one or moreoutput pins.
 4. The method according to claim 3, wherein the hardwarecomponent comprises one of the plurality of filters, and wherein thehardware component is selected from the group consisting of: ademultiplexer, a decoder, and a renderer.
 5. The method according toclaim 3, wherein the method is performed by a software componentcomprising one of the plurality of filters, the software componenthaving an input pin configured to receive media content units and anoutput pin configured for communication with the hardware component. 6.The method according to claim 5, wherein the method step of forming datastructures associated with each of the plurality of media content units,the data structures each having a field for storing information aboutthe storage locations of a particular media content unit, comprises:issuing, by the software component, a call to an application programminginterface (“API”) configured to receive information about a storagelocation of a particular media content unit and to populate the field ofthe a corresponding data structure with the information about thestorage location; and receiving, by the software component, a responsefrom the application programming interface exposing the field of thecorresponding data structure with the information about the storagelocation.
 7. The method according to claim 6, wherein the step ofarranging for exposing data structures to a hardware component comprisestransmitting, on the output pin configured for communication with thehardware component, the data structure with the field with theinformation about the storage location exposed.
 8. A method forpreparing media content as a media presentation by a software-basedmedia player including a decoder/renderer, the media content receivablefrom a media source as a plurality of media content units, the methodcomprising: identifying a portion of a memory for storing media contentunits comprising individually-presentable portions of clips receivedfrom the media source, the individually-presentable portions of clipsbeing multiplexed into a single program stream comprising the mediapresentation received at a hardware component, the hardware componentproviding scheduling information, responsively to a timing signal, tothe decoder/renderer to enable time-based synchronization of theindividually-presentable portions of clips; identifying a first mediacontent unit received from the media source; identifying a first storagelocation in which the first media content unit has been stored in theportion of the memory; forming a first data structure associated withthe first media content unit, the first data structure having a fieldfor storing information about the storage location; arranging forexposing the first data structure to the hardware component, theinformation about the storage location obtained from the first datastructure usable by the hardware component to directly access the firstmedia content unit from the memory without using a central processingunit; wherein the step of forming a first data structure comprises:issuing a call to an application programming interface (“API”)configured to receive information about the storage location and topopulate the field of the first data structure with the informationabout the storage location; and receiving a response from theapplication programming interface exposing the field of the first datastructure with the information about the storage location.
 9. The methodaccording to claim 8, wherein the method is performed within a mediaprocessing pipeline comprising a filter graph having a plurality offilters, each filter having one or more input pins and one or moreoutput pins.
 10. The method according to claim 9, wherein the method isperformed by a software component comprising one of the plurality offilters, the software component having an input pin configured toreceive media content units and an output pin configured forcommunication with the hardware component.
 11. The method according toclaim 10, wherein the step of arranging for exposing the first datastructure to a hardware component comprises transmitting, on the outputpin configured for communication with the hardware component, the firstdata structure with the field of the first data structure exposed. 12.The method according to claim 8, wherein the portion of the memoryallocated for storing media content units received from the media sourceis arranged as a ring buffer, the ring buffer having a beginning memoryblock and an ending memory block.
 13. The method according to claim 12,wherein the beginning memory block is duplicated, using virtual memory,after the ending memory block.
 14. The method according to claim 13,wherein the method further comprises the step of: when the storagelocation would include the beginning memory block and the ending memoryblock, storing a first portion of the first media content unit in theending memory block and a second portion of the first media content unitin the beginning memory block duplicated using virtual memory.
 15. Themethod according to claim 14 wherein after a particular media contentunit has been accessed, releasing the particular media content unit fromthe storage location.
 16. The method according to claim 12, wherein thering buffer is implemented using a begin pointer for referencing thebeginning of used memory in the ring buffer and an end pointer forreferencing the end of used memory in the ring buffer, and wherein thestep of identifying a first storage location for the first media contentunit in the allocated portion of the memory comprises identifying anoffset of the first media content unit within the ring buffer, theoffset specified relative to the begin pointer or the end pointer orboth.
 17. The method according to claim 16, the method furthercomprising: after the first media content unit has been transmitted,releasing the first media content unit from the first storage locationby moving the begin pointer or the end pointer or both.
 18. The methodaccording to claim 16, further comprising: maintaining a list of offsetpositions including storage locations of all media content units storedin the ring buffer; and using the list of offset positions to ensurethat the begin pointer and the end pointer do not bypass each other whenmedia content units are released from the storage locations.
 19. Anarchitecture for a media processing pipeline for use in a mediapresentation system, the architecture comprising: a software componentconfigured to receive media content units and to arrange for storage ofthe received media content units in a first memory; and a hardwarecomponent having a second memory, the hardware component responsive tothe software component and configured to transfer representations ofmedia content units stored in the first memory to the second memory,wherein said software component is operable to form a first datastructure, associated with a first media content unit, having a fieldfor storing information about a first storage location, by issuing acall to an application programming interface (“API”) configured toreceive information about the first storage location, and to populatethe field, and to receive a response from the application programminginterface exposing the field of the first data structure with theinformation about the first storage location, wherein the API isoperable at a boundary between said software component and said hardwarecomponent, the API configured to expose, at the request of said softwarecomponent, the at least one data structure field having informationabout the first storage location of first media content unit within thefirst memory to said hardware component, the exposed data structurefield enabling said hardware component to directly transferrepresentations of media content units stored in the first memory to thesecond memory without using a central processing unit.
 20. Thearchitecture according to claim 19, wherein the software component andthe hardware component comprise filters in a filter graph, the softwarecomponent has an output pin that connects to an input pin of thehardware component, and the API is responsive to a call from the outputpin of the software component to expose the data structure field to theinput pin of the hardware component.